home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
TeX 1995 July
/
TeX CD-ROM July 1995 (Disc 1)(Walnut Creek)(1995).ISO
/
tex-k
/
tex-k-archive.past
/
tex-k-archive.gz
/
tex-k-archive
/
000290_neal@ctd.comsat.com_Tue Feb 8 09:46:00 1994.msg
< prev
next >
Wrap
Internet Message Format
|
1994-10-11
|
2KB
Received: from neal.ctd.comsat.com by cs.umb.edu with SMTP id AA21648
(5.65c/IDA-1.4.4 for <tex-k@cs.umb.edu>); Tue, 8 Feb 1994 14:46:41 -0500
Received: by neal.ctd.comsat.com (Smail3.1.28.1 #29)
id m0pTyOO-0002fOC; Tue, 8 Feb 94 14:46 EST
Message-Id: <m0pTyOO-0002fOC@neal.ctd.comsat.com>
Date: Tue, 8 Feb 94 14:46 EST
From: neal@ctd.comsat.com (Neal Becker)
To: kb@cs.umb.edu
Cc: tex-k@cs.umb.edu
Subject: Engine specific font paths
In-Reply-To: <199402081711.AA22334@terminus.cs.umb.edu>
References: <199402081711.AA22334@terminus.cs.umb.edu>
>>>>> "K" == K Berry <kb@cs.umb.edu> writes:
K> (neal) There has to be a way to specify that you want fonts for a
K> particular engine. There also has to be a way to tell kpathsea
K> how/where to find fonts for different engines.
K> Any suggestions?
K> Yep, I have a suggestion :-)
K> I think the solution is to make your default PK path include
K> $MAKETEX_MODE, and then set that envvar (with putenv or xputenv
K> or whatever). As a bonus, MakeTeXPK ought to work.
Sounds interesting, but I don't know if this really does it. Let me
give you an example.
I can print in high res on my epson printer or low res. To do high
res I use fonts built for MF mode EpsonMXFX. For low res I made a
mode called EpsonMXFX-low.
When I want to print I have to tell the driver which I want. Using my
'eps' driver I use either an env variable or a command line switch to
tell it which mode I want. eps has a runtime config file telling it
what the name of the MF mode is. A config file tells the mctex
library how to find fonts for a particular MF mode.
I guess your suggestion using an env variable on PK path and then
relying on the driver to set the variable can work. I think it's kind
of circuitous though, and it won't work unless the (poor) user sets up
this nondefault PK path.
I'm still not sure what's the best approach. I'm inclined to say that
the driver needs to know what engine it's printing on. The driver
should obtain this knowledge ultimately from the user (possibly
through env variable or compile-time config) and pass this to the font
searching mechanism.